Simplify TypeFreshener methods.
#150239
Simplify TypeFreshener methods.
#150239
Conversation
`freshen_{ty,const}` take a `Result` and just do a fold if the input is
`Ok`. It's simpler to do those folds at the call site, and only call
`freshen_{ty,const}` in the `Err` case. That way we can also avoid
useless fold operations on the results of `new_{int,uint,float}`.
Also, make some `bug!` calls more concise.
rustbot
added
S-waiting-on-review
I have always found this confusingly named, because it creates a new freshener rather than returning an existing one. We can remove it and just use `TypeFreshener::new()` at the two call sites, avoiding this confusion.
Sometimes we freshen using a new `TypeFreshener`, and sometimes we freshen with an existing `TypeFreshener`. For the former we have the method `InferCtxt::freshen`. For the latter we just call `fold_with`. This asymmetry has been confusing to me. This commit removes `InferCtxt::freshen` so that all the freshening sites consistently use `fold_with` and it's obvious if each one is using a new or existing `TypeFreshener`.
Because `fresh_trait_pred` is the name of the field/argument. The `_ref` suffix appears to be a typo, or left over from earlier versions of the code.
It never happens in practice.
nnethercote
force-pushed
the
simplify-TypeFreshener-methods
branch
from
0d4649d to
2d10f47
Compare
| #[inline(never)] | ||
| fn fold_infer_ty(&mut self, v: ty::InferTy) -> Option<Ty<'tcx>> { | ||
| match v { | ||
| fn fold_infer_ty(&mut self, ty: ty::InferTy) -> Option<Ty<'tcx>> { |
There was a problem hiding this comment.
Yes! I have added a commit to remove the Option.
It's no longer needed.
|
Thanks for the suggestions, this has ended up much nicer than the first version. |
|
@bors try @rust-timer queue freshening should be at least somewhat hot? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…=<try> Simplify `TypeFreshener` methods.
rustbot
added
the
S-waiting-on-perf
|
Freshening is definitely hot, but freshening of inference variables is much less so. Local measurements indicated that the perf effects were negligible, but it doesn't hurt to double check. |
|
💥 Test timed out after |
|
@bors try |
This comment has been minimized.
This comment has been minimized.
…=<try> Simplify `TypeFreshener` methods.
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (d1d7c44): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResults (primary 2.1%, secondary 2.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 482.582s -> 480.862s (-0.36%) |
rustbot
removed
the
S-waiting-on-perf
4 participants
freshen_{ty,const}take aResultand just do a fold if the input isOk. It's simpler to do those folds at the call site, and only callfreshen_{ty,const}in theErrcase. That way we can also avoid useless fold operations on the results ofnew_{int,uint,float}.Also, make some
bug!calls more concise.r? @lcnr